The latest updates on your projects. Learn more about Vercel for Git ↗︎

@rafaeltab is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

I agree, the name stdout doesn't really convey the idea that prefixes are removed either. A pretty flag could cover this, however, we do not want to make this too complex either. Perhaps some baked-in pretty configurations, with the option to go custom would be best. Some ideas that come to mind are

turbo run build & turbo run build --pretty & turbo run build --pretty=normal: Current output

turbo run build --pretty=none: Remove prefixes, basically the current result from stdout-full

turbo run build --pretty=no-color: This would remove the color from the prefixes we have currently, it should not affect the logs themselves.

turbo run build --pretty=folder-name: This would log the folder name of the workspace instead of the package name

turbo run build --pretty="%Cred%pn%Creset: %O": Custom format, print the package name in red
%Cred to get color red, %pn for package name, %Creset to reset the color, %o for output

If we were to go for this option this would require a rewrite for a large portion of the logging system.
And of course more investigation, I believe that would fall out of the scope for this PR though, so how about implementing --pretty=none, --pretty, and --pretty=normal for now? That way the team can have some time to think this idea over properly, and probably create an internal or public RFC.

This would also allow the current stdout behavior to be combined with errors-only, which was left out in this PR.

how about implementing --pretty=none, --pretty, and --pretty=normal for now?

I think we can start with only true/false (defaulting to true). My suggestion to expand the flag was to demonstrate how --pretty would be more open for expansion, rather than to ask for this! Definitely don't go down the rabbit hole rewriting logging! :)

cc @gsoltis / @vercel/turbo-oss to help make a decision/bikeshed here as well.

One more thing to point out is that without prefixing, logs for tasks running in parallel will be mixed up. The prefixes are the only thing that let you differentiate between them right now. That may be a reason to add --pretty=no-color (which would leave prefixes) in addition to true/false options. Or it could just be documented if we decide to tackle #219 at some point.

I was absolutely not planning to rewrite logging just yet, the 3 possible options I could implement all represent either the no prefix logging or the normal logging, so the current implementation could almost completely work for them. Then when you guys decide you want to go all the way we won't have any backwards compatibility issues.

If you still prefer a simple boolean, that is also still an option. Would that be --pretty and --pretty false or --no-pretty or both.

The logs will indeed be mixed up, and --grouped would solve this, I am probably going to try picking that up once this is finished as well. It also seems to be the case that people don't want to remove the prefix because they think it is ugly, but because it screws up some CI mechanisms (such as set-output for github).

How about a separate boolean flag like --raw-output or --no-prefix-logs or something like that? That way it's separate from which logs to print. Would that cover what we need?

@gsoltis that would absolutely cover what we need. I think it's more a question of what do we want to add in the future when it comes to logging, and what do we think looks and feels better.

I believe --no-prefix, --no-prefix-logs, --raw-output & --pretty=false all cover what we currently need. The --pretty option allows for more future flexibility, and --no-prefix/--no-prefix-logs reflects the current behavior in the best way.

Do we want more flexibility, or de we want more clarity?

I see. Let's go with --raw-logs. I think that communicates what we're doing and optimizes for clarity now. If we need more flexibility in the future, we can either deprecate or mark as incompatible with whatever flags we end up needing then.

Can we take over this PR?

I have been a bit busy recently (I will be moving out of my parents' home to live with a friend of mine), I will continue development for this PR this week.

Hey @rafaeltab thanks for your work on this. We talked internally and landed on --log-prefix. I’ve started that work in #3851 and it’s my top priority tomorrow. We expect it to land in a 1.8.x patch release! Feel free to leave any feedback there! Also happy to share more of our thinking around the naming choice, etc.

Alright, it's understandable since I hadn't worked on it for a little while. The naming choice seems straightforward as well. I'll close this PR then. I'll probably end up picking up grouped output in the near future.